1. The Field of the Invention
The present invention generally relates to posting messages on a message board server. More particularly, the present invention provides for extending the data properties and functionality of a legacy messaging board protocol without having to modify the legacy protocol in order to support clients with only legacy protocol capabilities.
2. Background and Related Art
Bulletin board services (BBSS) or messaging board services are systems that allow users to post and download public messages. These messaging board services normally have many different file libraries and discussion groups so that clients can communicate with one another through an on-line connection.
Typically, messaging board services can be provided as part of a large on-line network where users post messages to various groups within the message board service so that many different users can read their message. For example, a client may post a message to the message board server requesting information on a particular software program. Other users of the network service can read this message and respond by posting messages of their own, which may include such things as a comment, suggestion or an answer. Typically all of these messages are publicly available and can be read by any user.
In order to post and download messages, a client and a server need to communicate over the network through a specific protocol. The protocol may defined how data is exchanged over the server, how the server and client logically organize data being requested or provided, and authentication and the channel protection used to secure the connection. One predominate protocol used by computer clients and servers for managing message threads posted on a message board service is known as network news transfer protocol (NNTP). An NNTP client may be included as part of most any Web browser or may use a separate client program called a news reader. In any event, NNTP has become the predominate protocol for interacting with newsgroups.
Regardless of the protocol used, however, it may be desirable to extend the data properties and functionalities of a particular messaging board protocol. For example, some protocols are unsecured with no way of authenticating a user or, like NNTP, offer limited security options. With no way to authenticate or provide for a secure connection, there is no true reliability in the identity or status of an author of a message nor is there any way to protect data from being tampered with. Further, messaging board protocols are static in that data properties associated with the posting cannot easily be updated or dynamically changed. This is due to various reasons, such as the difficulty in getting a change through a standards committee. As mentioned in greater detail below, however, even if you can get a change approved, significant changes in the protocol will likely break legacy clients that don't support these changes. Still, there are a number of other reasons for extending messaging board protocols.
Typically, when displayed, messages are formatted in a conversation threading structure or tree structure. This thread structure generally includes one or more message references based on unique message identifiers. In this conversation threading scheme, related news messages are grouped together by topic. A topic or conversation generally includes a root within a hierarchy of replies or reply messages. The replies or reply messages are commonly referred to as children of the conversation root, and may include sub-topic branches.
Based on the message references and identifiers, a message thread typically is arranged so that the conversation can retain its original flow or order. Specifically, the thread can be arranged so that the conversation root is displayed first and reply messages are displayed thereafter in the order in which each is received. The thread also accommodates reply messages that stem from other reply messages and so forth. Among other things, this conversation threading allows messages to be retrieved from a server and read in a logical order.
One problem associated with the current thread structures is that a user must browse through much of a thread in order to determine whether the thread represents an ongoing conversation or a conversation that has ended. For example, some companies employ software experts who monitor and respond to questions posted on their message board server. With traditional message board protocols and clients, the expert must go through each conversation thread to determine if there is a question, and whether there has been an appropriate answer to that question. As can be appreciated, this becomes a time- and labor-intensive process. As such, it is desirable to be able to identify message threads based on some user-specified criteria, like whether a question has been sufficiently answered. Again, however, such functionality would also require the extension of typical message board protocols.
Clearly one solution to overcoming the deficiencies of current messaging board protocols would be to modify the protocol itself. There are, however, several problems associated with such a solution. For example, such modification of the protocol may require most if not all users to update their client software. Accordingly, users with legacy clients that implement the legacy protocol would not be supported with the change in data properties and functionalities. Further, there are instances where the server or client software implementation of the protocol cannot be modified in an elegant way because design choices preclude simple solutions to new problems. Accordingly, it is desirable to be able to extend the functionality and data properties offered by a legacy protocol, without having to modify the legacy protocol itself.